Application developers frequently use application programming interfaces (APIs) to build software applications. An API is a set of programming instructions and standards for accessing a software application. Software vendors often release their own APIs to the public so that other software developers can design products that can access or utilizes their services. Interfacing with remote and local APIs is typically a highly repetitive task that consists of writing custom code, which comprises a great deal of tedious and quasi-repetitive functions to query, retrieve, transform, act and iterate on data that is obtained from the API. Not only must such code be written in the first instance, but also it must be regularly maintained and updated to accommodate changes to the applications and interfaces.
What is needed, therefore, is a system and method for API workflow engine that reduces the development effort and recurring support costs associated with developing applications that communicate with APIs by providing a methodology and workflow that allows application developers to interact with APIs without requiring the need to write or maintain extensive amounts of repetitive code.
Applications written for large-scale networks, such as data backup applications, such as exemplified by the Data Domain products from EMC Corp. involve the interaction of many different networked components. Performing the discovery of devices contained within a target infrastructure such as data storage arrays (e.g., VMAX, RecoverPoint, DataDomain, etc.) is a function performed by many different software products. This task also implicates the interaction of APIs, and as the software required to implement discovery is typically a rote and well-known process, writing custom code is generally a time-consuming and inefficient process.
What is yet further needed, therefore, is a programming model whereby various APIs, devices, or device types are described by configuration information that concisely describes the desired data, and without the need for writing custom code for each device or device type.
The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.